overlay.d/15fcos: add a migration script to move to OCI images #3355
Conversation
jbtrystram
changed the title
|
There is at least one missing bit here : I found out that when faking the origin file, |
|
|
||
| motd_path=/run/motd.d/40-fcos-oci-rebase.motd | ||
|
|
||
| cat << EOF > "${motd_path}" |
There was a problem hiding this comment.
I think we should have a separate script that writes out the MOTD and it should run on every boot unless the user has neutered it by touching a stamp file.
There was a problem hiding this comment.
basically we can roll out the MOTD script later (i.e. like a month in to F42 or something).
|
|
||
|
|
||
| # Restart Zincati | ||
| systemctl restart zincati |
There was a problem hiding this comment.
this happening here leads to temporary problems.. basically if there is an update available $now (which I guess is unlikely but could be the case when older systems are jumping through this new barrier we are going to create) then zincati will do it's thing and rpm-ostree will too, but if rpm-ostreed hasn't timed out and deactivated since we wrote the custom origin file then it will complain:
Feb 27 22:01:40 cosa-devsh rpm-ostree[3917]: Txn Deploy on /org/projectatomic/rpmostree1/fedora_coreos failed: Cannot look up version while tracking a container image reference
Maybe we should restart rpm-ostreed here too just to make sure it's picked up the new custom origin?
There was a problem hiding this comment.
Interesting scenario, I didn't thought of that.
This definitely requires more testing in these corner cases.
|
One thing I notice that isn't great is it still says is that expected? |
|
Also on the system I see a bunch of these messages. Not sure if we can do anything about them: |
| cincinnati_url="https://raw-updates.coreos.fedoraproject.org/v1/graph?basearch=$arch&stream=$stream&oci=true" | ||
| imgref=$(curl "$cincinnati_url" -s | jq --arg VERSION "$version" -r '.nodes[] | select(.version==$VERSION) | .payload') |
There was a problem hiding this comment.
We should make a failure here nonfatal. IIUC the reason for the curl is more cosmetic than anything else (so rpm-ostree status shows something not unexpected), but if it fails for whatever reason I think we should continue the migration.
Things that could cause this to fail could be complicated network environments like proxies, or maybe wifi where the NIC hasn't come up fully yet or something.
There was a problem hiding this comment.
It's not only cosmetic : Zincati will use that digest to find $currentNode in the graph.
https://github.com/coreos/zincati/blob/fb745a46c980827959763bcaaecdb4363a35321f/src/cincinnati/mod.rs#L231
There was a problem hiding this comment.
So i guess if the update server is proxied we need to pull that info from the Zincati config
There was a problem hiding this comment.
I added a knob and checked for failure
I guess that's a byproduct of faking out the origin file |
Yes. Because otherwise we cannot communicate which stream the node is following, as the digest does not show that information. |
jbtrystram
force-pushed
the
oci-migration-script
branch
from
f330048 to
526b944
Compare
|
@dustymabe @jlebon I tweaked this script adding some logging, handling failures and allowing to override the cincinnati address for proxied environments. I also stop rpm-ostree and zincati while overwriting the origin file to avoid a race or conflict. |
To simplify testing for coreos/fedora-coreos-tracker#1823 ship a script to fake the ostree origin to appear like it's on an OCI deployement. Just ship the migration script for now, without the systemd unit, to allow testing.
jbtrystram
force-pushed
the
oci-migration-script
branch
from
526b944 to
9e5f50e
Compare
to simplify testing for coreos/fedora-coreos-tracker#1823
ship a script to fake the ostree origin to appear like it's on an
OCI deployement.
Just ship the migration script for now, without the systemd unit, to allow testing.